smartcontract: add support for NEP-25 #4036

Turalchik · 2025-10-10T09:27:55Z

codecov · 2025-10-10T09:33:32Z

Codecov Report

❌ Patch coverage is 88.38583% with 59 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.49%. Comparing base (3d162dc) to head (8cccd96).
⚠️ Report is 32 commits behind head on master.

Files with missing lines	Patch %	Lines
pkg/smartcontract/manifest/parameter.go	78.31%	11 Missing and 7 partials ⚠️
pkg/smartcontract/rpcbinding/binding.go	73.43%	16 Missing and 1 partial ⚠️
pkg/smartcontract/manifest/extended_type.go	92.99%	10 Missing and 5 partials ⚠️
pkg/compiler/debug.go	91.86%	6 Missing and 1 partial ⚠️
pkg/compiler/codegen.go	95.83%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4036      +/-   ##
==========================================
+ Coverage   72.48%   74.49%   +2.01%     
==========================================
  Files         364      365       +1     
  Lines       56750    47958    -8792     
==========================================
- Hits        41135    35727    -5408     
+ Misses      13880    10490    -3390     
- Partials     1735     1741       +6

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

roman-khimov

semantic checks
stack item serialization

See neo-project/neo#4043 also

roman-khimov · 2025-10-10T10:08:24Z

cli/smartcontract/smart_contract.go

-	Overloads          map[string]string               `yaml:"overloads,omitempty"`
-	NamedTypes         map[string]binding.ExtendedType `yaml:"namedtypes,omitempty"`
+	Overloads          map[string]string                `yaml:"overloads,omitempty"`
+	NamedTypes         map[string]manifest.ExtendedType `yaml:"namedtypes,omitempty"`


Likely it's no longer needed here, manifest has it all.

Do I need to write an UnmarshalYAML method for ProjectConfig or mark the NamedTypes field as deprecated?

Just drop them and then let's see how it goes.

roman-khimov · 2025-10-10T10:10:21Z

pkg/smartcontract/manifest/extended_type.go

+
+import (
+	"encoding/json"
+	"gopkg.in/yaml.v3"


Likely we no longer need yaml here.

AnnaShaleva

Please, adjust the PR/commit description, it points to the wrong issue.

AnnaShaleva

Please, check the compatibility with the reference implementation, especially in the part of extended type verification and circular references.

cli/smartcontract/testdata/rpcbindings/invalid5/invalid.yml

AnnaShaleva · 2025-10-30T09:57:46Z

cli/smartcontract/testdata/rpcbindings/notifications/config_extended.yml

        extendedtype:
          base: Struct
          name: crazyStruct
+          fields:
+            - field: I
+              base: Integer
+            - field: B
+              base: Boolean


Why do you include fields in the definition of named extended type? It shouldn't be like that, all named types should be specified in the namedtypes section, and extended type here should just point to a specific named type.

We no longer store namedtypes in the config, so I don't quite understand where the author should specify the definition of named type.

We no longer store namedtypes in the config

They still should be presented in a separate section of config file, like it's done for manifest (https://github.com/neo-project/proposals/blob/master/nep-25.mediawiki#contract). Otherwise, we have to declare named type in-place every time it's used in the contract config. Consider the same named type used in multiple events, for example.

This namedtypes section of config will be relevant for events only and will likely be removed once we solve #3027. Until this issue is solved, namedtypes section is the only place that can be used for manifest's events construction.

@roman-khimov, I need your opinion here because it was your request (https://github.com/nspcc-dev/neo-go/pull/4036/files#r2419192068). So far, we used config-based events for type casting at the compiler level and to compare the emitted event types with the desired ones. If we still want to support this feature, then we need namedtypes section to be resented in the contract config. ACK?

OK, keeping them isn't hard. I've not seen code throwing structures in events (other than examples), but #3027 seems to be the key here.

cli/smartcontract/generate_test.go

pkg/compiler/compiler.go

AnnaShaleva · 2025-10-30T12:31:22Z

pkg/smartcontract/manifest/extended_type.go

+	if err := node.Decode(&raw); err != nil {
+		return err
+	}
+	if v, ok := raw["base"]; ok {


From what I understand, there shouldn't be base field.

JSON format should be compatible with C#.

I thought I needed to support the old format, but I don't need to do that, right?

Right. No old format support, we'll migrate to the NEP-25 without transition period.

pkg/smartcontract/manifest/extended_type.go

AnnaShaleva · 2025-10-30T12:34:42Z

pkg/smartcontract/manifest/extended_type.go

+		if e.Base != smartcontract.InteropInterfaceType {
+			return fmt.Errorf("`ExtendedType.Interface` field can not be specified for %s", e.Base)
+		}
+		if e.Interface != "IIterator" {


There should be a constant for IIterator in our codebase.

I found the constant only here

neo-go/pkg/neorpc/result/invoke.go

Line 48 in 2ffd0fd

const iteratorInterfaceName = "IIterator"

Make it exported, move to a suitable package and reuse.

AnnaShaleva · 2025-10-30T12:37:04Z

pkg/smartcontract/manifest/extended_type.go

+		}
+		e.Fields[i] = p
+	}
+	return nil


We should heck if the resulting type (and all nested ones) are valid.

should we call the Valid() method? why don't we do this for, for example, manifest.Parameter?

should we call the Valid() method?

Yes. Check the reference implementation for that.

why don't we do this for, for example, manifest.Parameter?

Check how it's handled in the reference implementation and attach the link to the discussion.

pkg/smartcontract/manifest/extended_type.go

Close #3595. Signed-off-by: Tural Devrishev <[email protected]>

AnnaShaleva · 2025-11-10T16:59:40Z

cli/smartcontract/testdata/rpcbindings/notifications/config_extended.yml

        extendedtype:
          base: Struct
          name: crazyStruct
+          fields:
+            - field: I
+              base: Integer
+            - field: B
+              base: Boolean


We no longer store namedtypes in the config

They still should be presented in a separate section of config file, like it's done for manifest (https://github.com/neo-project/proposals/blob/master/nep-25.mediawiki#contract). Otherwise, we have to declare named type in-place every time it's used in the contract config. Consider the same named type used in multiple events, for example.

This namedtypes section of config will be relevant for events only and will likely be removed once we solve #3027. Until this issue is solved, namedtypes section is the only place that can be used for manifest's events construction.

@roman-khimov, I need your opinion here because it was your request (https://github.com/nspcc-dev/neo-go/pull/4036/files#r2419192068). So far, we used config-based events for type casting at the compiler level and to compare the emitted event types with the desired ones. If we still want to support this feature, then we need namedtypes section to be resented in the contract config. ACK?

AnnaShaleva · 2025-11-11T09:18:31Z

pkg/compiler/codegen.go

+					name := "unnamed"
+					if c.buildInfo.options.CollectedNamedTypes != nil {
+						for c.buildInfo.options.CollectedNamedTypes[name].Name == name {
+							name = name + "X"
+						}
+						_ = c.genStructExtended(typ, name, c.buildInfo.options.CollectedNamedTypes)
+					}


Duplicating code.

AnnaShaleva · 2025-11-11T09:19:57Z

pkg/compiler/codegen.go

+		return
+	}
+	var (
+		seen = make(map[types.Type]bool)


map[types.Type]struct{}

AnnaShaleva · 2025-11-11T09:22:22Z

pkg/compiler/compiler.go

-	// GuessEventTypes specifies if types of runtime notifications need to be guessed
-	// from the usage context. These types are used for RPC binding generation only and
+	// GuessedNamedTypes specifies guessed from the usage context named types of
+	// runtime notifications. These types are used for RPC binding generation only and


Add a note that it's nil in case if ...

AnnaShaleva · 2025-11-11T09:23:29Z

pkg/compiler/compiler.go

 	// can be defined for events with name known at the compilation time and without
-	// variadic args usages. If some type is specified via config file, then the config's
-	// one is preferable. Currently, event's parameter type is defined from the first
+	// variadic args usages. Currently, event's parameter type is defined from the first


Changes regarding config file may be reverted after the resolution of https://github.com/nspcc-dev/neo-go/pull/4036/files#r2511308314.

Just don't forget we have two configs currently, contract-level and bindings-level, contract one stays in some form anyway, but bindings only need a manifest.

AnnaShaleva · 2025-11-11T12:53:42Z

pkg/smartcontract/manifest/extended_type.go

+		pa := &e.Fields[i]
+		pb := &other.Fields[i]


Just a and b.

AnnaShaleva · 2025-11-11T12:56:05Z

pkg/smartcontract/manifest/extended_type.go

+	if err := node.Decode(&raw); err != nil {
+		return err
+	}
+	if v, ok := raw["base"]; ok {


Right. No old format support, we'll migrate to the NEP-25 without transition period.

AnnaShaleva · 2025-11-11T12:57:20Z

pkg/smartcontract/manifest/extended_type.go

+		}
+		e.Fields[i] = p
+	}
+	return nil


should we call the Valid() method?

Yes. Check the reference implementation for that.

why don't we do this for, for example, manifest.Parameter?

Check how it's handled in the reference implementation and attach the link to the discussion.

AnnaShaleva · 2025-11-11T12:58:10Z

pkg/smartcontract/manifest/extended_type.go

+		if !unicode.IsLetter(rune(e.Name[0])) {
+			return errors.New("`ExtendedType.Name` must start with a letter")
+		}


If we use regexp, then this logic should be a part of regexp. Check the reference implementation.

AnnaShaleva · 2025-11-11T12:59:46Z

pkg/smartcontract/manifest/extended_type.go

+		if e.Base != smartcontract.InteropInterfaceType {
+			return fmt.Errorf("`ExtendedType.Interface` field can not be specified for %s", e.Base)
+		}
+		if e.Interface != "IIterator" {


Make it exported, move to a suitable package and reuse.

AnnaShaleva · 2025-11-11T15:51:57Z

We also need to port Faun-related logic, ref. https://github.com/neo-project/neo/pull/4283/files#diff-56a96400470d169fb83598d289f068d661f906f74e2432ea3685988611331f12R193-R196

AnnaShaleva · 2025-11-11T15:53:11Z

pkg/smartcontract/manifest/extended_type.go

+	alphaNumDot = regexp.MustCompile(`^[A-Za-z0-9.]+$`)
+)
+
+type ExtendedType struct {


Exported type needs comment.

Turalchik requested review from AnnaShaleva and roman-khimov as code owners October 10, 2025 09:27

Turalchik marked this pull request as draft October 10, 2025 09:28

roman-khimov reviewed Oct 10, 2025

View reviewed changes

Turalchik force-pushed the support-nep-25 branch 3 times, most recently from 0457d1a to a8966da Compare October 20, 2025 06:26

Turalchik marked this pull request as ready for review October 20, 2025 06:26

Turalchik requested a review from roman-khimov October 20, 2025 06:47

AnnaShaleva changed the title ~~smartcontract: add support NEP-25~~ smartcontract: add support for NEP-25 Oct 22, 2025

AnnaShaleva reviewed Oct 27, 2025

View reviewed changes

Turalchik force-pushed the support-nep-25 branch from a8966da to 2ffd0fd Compare October 27, 2025 10:05

AnnaShaleva reviewed Oct 30, 2025

View reviewed changes

smartcontract: add support NEP-25

8cccd96

Close #3595. Signed-off-by: Tural Devrishev <[email protected]>

Turalchik force-pushed the support-nep-25 branch from 2ffd0fd to 8cccd96 Compare November 1, 2025 15:01

AnnaShaleva added the blocked Can't be done because of something label Nov 6, 2025

AnnaShaleva reviewed Nov 11, 2025

View reviewed changes

smartcontract: add support for NEP-25 #4036

Are you sure you want to change the base?

smartcontract: add support for NEP-25 #4036

Uh oh!

Conversation

Turalchik commented Oct 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

codecov bot commented Oct 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

roman-khimov left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

AnnaShaleva left a comment

Choose a reason for hiding this comment

Uh oh!

AnnaShaleva left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Turalchik commented Oct 10, 2025 •

edited

Loading

codecov bot commented Oct 10, 2025 •

edited

Loading